Cross-repo CI audit found juniper-data-client's bandit step was a
single ``bandit … || true`` with no follow-up blocking invocation, so
any genuine finding was silently tolerated. Mirror the canonical
two-step pattern used in cascor / data (and now extended in
juniper-data PR #67):

1. **SARIF generation** — ``bandit … -f sarif -o ... --exit-zero``.
   Always succeeds so the GitHub Security upload has a file regardless
   of findings.
2. **Blocking gate** — ``bandit … --confidence-level medium
   --severity-level medium``. Fails the job on medium-or-higher
   findings.

Also harden the SARIF upload with
``hashFiles('reports/security/bandit.sarif') != ''`` to keep the
upload step green if a future security-tools regression prevents
bandit from emitting the file.

Verified locally — current ``juniper_data_client`` has 0 medium /
high findings, so the new gate is non-blocking on this commit. Any
future medium-or-higher finding will now fail CI.

Refs cross-repo CI audit P-20.